Upon successful introspection, regardless of the token type or introspection method, a response with the boolean `active` is returned, indicating if the provided token is active and if the requesting client is part of the token audience. If `active` is true, further information will be provided:

| **Property** | **Description** |
| --- | --- |
| `aud` | The audience of the token |
| `client_id` | The client_id of the application the token was issued to |
| `exp` | Time the token expires (as unix time) |
| `iat` | Time the token was issued at (as unix time) |
| `iss` | Issuer of the token |
| `jti` | Unique id of the token |
| `nbf` | Time the token must not be used before (as unix time) |
| `scope` | Space delimited list of scopes granted to the token |
| `token_type` | Type of the inspected token. Value is always Bearer |
| `username` | ZITADEL's login name of the user. Consists of username@primarydomain |


Depending on the granted scopes, additional information about the authorized user is provided. 

If the authorization fails, an HTTP 401 with invalid_client will be returned.

In summary, the introspection endpoint plays a crucial role in validating access tokens, either opaque or JWT, ensuring that they are not revoked. 
